\section{Immutability in the Mainstream Programming Languages}
\label{s:immutability-current}

%\mde{This section does not do as it claims to do:  it only describes
%  existing features (that have little to do with immutability) in existing
%  languages rather than overview ways to support immutability, which
%  actually happens later in Section~\ref{s:major-proposals}.  So, what is
%  the point of this section, and what is the real structure of the
%  chapter?}

%This section discusses different ways to provide support for
%immutability in an object-oriented language. For example, this can be done by extending
%the static types with immutability information in a way similar to
%generic types or by providing support for effects of each individual
%method and checking the requirements specified by the effects type
%system.

In non-functional object-oriented languages immutability support
is extremely limited. The only clear examples are the use of
\Cconst{} in C++ and the use of the \kw{final} keyword in Java, which
we shall see are not enough to guarantee immutability of objects.
We discuss existing support in popular languages and in the following Section we look into
how recent proposals improve the state of affairs.


\subsection{C++ \ {\large\tt{const}}}

\mde{I would find this section (and all sections) easier to read if they
  explicitly stated, for each immutability system, its choices regarding
  abstract vs.~concrete, all fields vs.~some, shallow vs.~deep, object
  immutability vs.~read-only references, etc.}

C~\cite{KernighanR88} and C++~\cite{Stroustrup00:CPL} provide a
\Cconst{} keyword for specifying immutability.
C++'s \Cconst{} keyword is more commonly used as an aid when declaring interfaces, rather than as a way of declaring symbolic constants~\cite{Stroustrup00:CPL}.
Furthermore, there are a number of pitfalls that led Java's designers to omit \Cconst{}.

Because of numerous loopholes, the \Cconst{} notation in C++ does
not provide a guarantee of immutability even for accesses through
the \Cconst{} reference. First, an unchecked cast can remove
\Cconst{} from a variable.  Second, C++'s \Cconstcast{} may also
be applied arbitrarily and is not dynamically checked.  The
\Cconstcast{} operator was added to C++ to discourage, but not
prohibit, use of C-style casts, accidental use of which may
convert a read-only pointer\mde{The notion of ``read-only pointer'' has not
  been introduced.  The text should both define it and explain how it is
  related to C++ const.}
or reference to a mutable one. Third,
because C++ is not a type safe language, one can (mis)use type
system weaknesses such as unions and varargs (unchecked
variable-length procedure arguments) to bypass the restrictions
on mutability prescribed by \Cconst{}.

Another criticism of C++'s \Cconst{} is that
C++ does not permit parameterization of
code based on the immutability of a variable.
Use of \Cconst{} may lead to code
duplication, where several versions of a function are needed
depending on \Cconst{}-ness. An example is the two versions of
\mytt{strchr} in the C++ standard library.

Finally, declaring a method as \Cconst{} (or read-only) only stops it from modifying the receiver and does not prevent it from modifying any other objects. Thus, a \Cconst{} (read-only) method in C++ is not a \textit{pure} method.

C++'s \Cconst{} is shallow with respect to pointers but deep with respect
to fields.
C++ permits the contents of a read-only pointer to be modified, and
read-only methods protect only the local state of the enclosing
object.  To guarantee transitive non-mutability, an object's state must be
(transitively) held directly in variables/fields rather than accessed by
a pointer.  However, this
precludes sharing, which is a serious disadvantage.  Additionally,
whereas C++ permits specification of \Cconst{} at each level of pointer
dereference, it does not permit doing so at each level of a
multi-dimensional array.

Most C++ experts advocate the use of \Cconst{} (for example,
Meyers advises using \Cconst{} wherever possible~\cite{Meyers97}).
However, as with many other type systems (including those of C++
and Java), some programmers feel that the need to specify types
outweighs the benefits of type checking.
%\COMMENTJOHAN{It's not very clear what this means?  Is it positive or negative?}.
At least three studies have found that static type checking reduces
development time or errors~\cite{Morris1978,Gannon77,PrecheltT98}.
\mde{There are also papers by Hanenburg that claim to show no benefit from
  static typing; but their methodology is so suspect that I'm happy not to
  cite them, as they don't deserve the attention.}
We are not aware of any empirical (or other) evaluations regarding
the costs and benefits of immutability annotations.

%Java programmers seem eager for compiler-checked immutability
%constraints: as of March 2005, support for \Javaconst{} was the second
%most popular Java request for enhancement.
% On March 19, 2005, the RFE was closed --- the state was changed to
% ``Closed, will not be fixed''.

A common criticism of \Cconst{} is that transforming a large
existing codebase to achieve \Cconst{} correctness is difficult,
because \Cconst{} pervades the code: typically, all (or none) of a
codebase must be annotated.  This propagation effect is
unavoidable when types or externally visible representations are
changed.  Inference of \Cconst{} annotations (such as that
implemented by Foster et al.~\cite{FosterFFA99}) eliminates such
manual effort.  Even without a type inference, some~\cite{TschantzE2005} found the work of annotation to be
greatly eased by fully annotating each part of the code in turn
while thinking about its contract or specification, rather than
inserting partial annotations and attempting to address type
checker errors one at a time.  The proper solution, of course, is
to write \Cconst{} annotations in the code from the beginning,
which takes little or no extra work, as the designer should have
already made decisions about mutability.


\subsection{Java \texttt{final}}

% http://stackoverflow.com/questions/4971286/javas-final-vs-cs-const

Java~\cite{gosling:2005:java} does not support \Cconst{}.
Instead a \kw{final} keyword was introduced. Java does not have a
concept of ``\Cconst{} references'', and so there is no support
for final methods, in the sense that only such methods would be
invokable on final receivers.  (In Java, \kw{final} applied to a method
means something entirely different:  the method
cannot be overridden in a subclass.) Similar to C++,
marking a member as \kw{final} only protects the variable, not the
object the variable refers to, from being mutated. Thus,
immutability in C++ and Java is not \textit{transitive}.


\subsection{Immutability in Non-Object-Oriented Languages}

Functional languages, such as ML~\cite{MilnerTH90}, default all
variables to being immutable. OCaml~\cite{OCaml:Manual} combines
object-orientation with a \code{mutable} annotation on fields (for
example, references are implemented as a one-compartment mutable
record). However, there is little support from type systems to
distinguish \textit{mutable} operations from \textit{read-only}
operations.


%%% Local Variables: 
%%% TeX-command-default: "PDF"
%%% End: 

% LocalWords:  const mis varargs ness strchr readonly OIGJ Javari's
